Modern computer applications, such as document creation programs, Internet applications, and so forth, require a large number of files and system settings to function properly. The term, “application” is to be interpreted broadly to include, for example and without limitation, a stand-alone application, which may be associated with a plurality of files and system settings; a run-time library, such as Microsoft's DirectX® package, Sun Microsystem's Java run-time library, etc.; or a plug-in or extension, such as Adobe Flash® browser plug-in, Adobe Reader®, etc. In general, any file or group of files and/or system settings may, for present purposes, be considered an “application.”
FIG. 1 shows exemplary computer system 10 having an application installed thereon. Computer system 10 includes one or more data buses 18 interconnecting one or more central processor units (CPUs) 12, a user interface 14, network interface 16, and memory system 20. User interface 14 may, for example, comprise a keyboard, mouse inputs, audio and video outputs, etc. (not shown). Memory system 20 may comprise a plurality of memories (not shown) for storing data and instructions for execution on CPU(s) 12. Each memory may include a machine readable medium. The memories making up memory system 20 may include, for example, volatile and non-volatile memories and caches. Memory system 20 may additionally include remote memory (not shown), e.g., memory or file systems accessible via network interface 16 or through an additional in/out (I/O) interface or bus (not shown). Those skilled in the art will recognize that FIG. 1 is a simplified diagram of computer system 10, and that a typical computer system will include many additional components and subcomponents not represented herein for the purpose of brevity.
In the present example, memory system 20 stores executable application file 22, which is a file containing computer instructions causing the computer to perform functions according to the purpose of the application. In addition, memory 20 may include ancillary files 24 which may contain data or additional executable code. Ancillary files 24 may be installed onto memory system 20 according to an installation program or script (not shown) at the time application executable 22 is installed. Memory system 20 also includes shared files 26. Shared files 26 may be pre-existing, i.e., already present on the system prior to the installation of application executable 22, or they may be installed at the time application executable 22 is installed. A distinction between shared files 26 and ancillary files 24 is that shared files 26 are registered with the operating system and/or located in memory system 20 such that other applications (not shown) can access and utilize the shared files. In the example of FIG. 1, shared files 26 include one or more dynamically linked library (DLL) files 28. Finally, an operating system (OS) 28 is present on memory system 20. The operating system includes files containing system settings 30. In the Microsoft Windows® operating system, the system settings are referred to as “registry settings” and are stored in a data tree structure formed by several files. When the application is installed, system settings may be created and stored along with system settings for the operating system as well as for other, previously-installed applications.
It is not uncommon for the installation of a single application to include the copying of hundreds of individual data files, code libraries, and system settings, along with one or more executable program files. Furthermore, files may be copied to disparate locations within a logical structure of the file system, referred to herein as a “directory.” The directory is made up of numerous folders logically organized in a hierarchical structure. When installing an application, some files may be copied to a main installation folder (e.g., “c:\Windows\Program Files\Application” in Windows) whereas other files may be copied to system folders, “common” folders, user folders, or folders subordinate to the main installation folder.
To further complicate application installations, many applications today have numerous dependencies on pre-installed applications, shared libraries, and system settings. As a result of the complex interdependent nature of many applications, in some instances some applications cannot coexist on a single system with other applications (such as other versions of the software) while at the same time may require certain other applications to be previously installed on the platform. For example, many applications such as Microsoft Internet Explorer do not allow multiple versions of a particular package to be installed on the same platform. Furthermore, two different applications may require different versions of a shared file. The possibility of overwriting of an existing file when installing an application could cause a previously installed application that relies on the overwritten file to break. Likewise, there are many applications that require the presence of a secondary installation package to run. For example, any application that uses Microsoft's .NET framework or Sun Microsystem's Java runtime engine first requires installation of Microsoft .NET or Java, respectively.
To solve these and other problems, it has been known to “virtualize” a single application or a group of applications, thereby isolating these applications from one another and from system software, i.e., the operating system. By providing a thin software layer logically interposed between the operating system and the application, a virtualized application can execute without installing any files or modifying the system directory or system settings. During execution, queries for any file or registry setting are redirected to a “sandbox.” If the file or registry setting is not present in the sandbox, then the query is directed through normal OS application programming interfaces (APIs).
Application virtualization successfully isolates an application from the remainder of the system and allows for enhanced security and policy enforcement, which are features desirable in enterprise environments. However, application virtualization requires that files and settings on which the application depends must either be present on the host platform or be present within the virtualized application package. Therefore, if a program for example requires the Java runtime library to operate, the entire Java runtime library must either be installed on the host platform or be present in the virtualized application package.